|
![](/i/fill.gif) |
In article <402d4192@news.povray.org>,
"Thorsten Froehlich" <tho### [at] trf de> wrote:
> It is absolutely necessary. What you expect is functions to have a scope on
> the same level as macros do. This is not the case, and you don't want it to
> be the case either (it is possible to construct cases where, if this would
> be the case, it would badly break functions - i.e. when generating a
> function with macros).
Would it necessarily do so? I don't see how it could be a problem for a
parameter name to hide a parse-time variable name. The person writing
the function could change the parameter name if the variable is needed,
otherwise it just avoids situations like this one.
> The solution is that the include files should not use generic names for
> function variable names. A good solution would be to use all lower case
> variable names with a prefix, i.e. "math__a" (note the *two* underscore
> chars, this makes sure this will never be a keyword) instead of "A" in
> math.inc . This would work because the documentation already suggests to
> the user to never use all lower case names.
Shorter: end the name with an underscore: a_
A keyword won't end with an underscore, and variable names typically
don't either, aside from it being recommended to use upper case letters
in them. I don't see a reason for the parameters to conflict with
parse-time variables, though.
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tag povray org>
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |